API: Allow caching for output ports #602
Conversation
This commit reverts 3d97601 ("More documentation in jack.h") partly. The following call stack is used: jack_port_get_buffer() JackGraphManager::GetBuffer(jack_port_id_t, jack_nframes_t) JackGraphManager::GetBuffer(jack_port_id_t) JackPort::GetBuffer() To call JackGraphManager::GetBuffer(jack_port_id_t, jack_nframes_t) the object JackLibGlobals::fGlobals->fGraphManage is used. It is only set in JackLibClient::Open(). Therefore it is not changed in the life time of a JACK client. In case port->fTied will be modified at runtime the returned audio buffer would change. This variable can only be modified by the deprecated jack_port_tie() function. Therefore as long as not calling this deprecated function the audio buffer would not change. The previous analyses is only valid for JACK audio output ports (JackPortIsOutput). The creating JACK client can write to those ports. For JACK audio input ports (JackPortIsInput) it is still not allowed to cache the audio buffer address because for those ports the returned audio buffer is depending on the port connections (pipelining). The decision for the pipelining is done in JackGraphManager::GetBuffer(jack_port_id_t, jack_nframes_t). Change-Id: Ief1cd18d018d5e407876630c22254d87f3c55442 Signed-off-by: Timo Wischer <[email protected]>
|
Hello @sletz, Is there a misunderstanding in the comment or is it even for JACK2 not required and caching output ports is with the already mentioned limitations still allowed? |
|
The caching is not mentioned in the jack1 headers at https://github.com/jackaudio/headers/blob/master/jack.h#L643 |
|
This "pipelining" experimental development was actually never merged, so yes caching for output ports is safe. |
|
Alright, thanks! |
|
@twischer-adit can you add a note about port-tie? It is a deprecated API, but only because it ended up not being used by client applications. as far as I know, ladish is the only one that uses it also, should be noted that this is a jack2-specific behaviour. |
|
Hi @falkTX,
Should I add the corresponding commit description as a comment into the source code
As far as I understand it is also allowed to cache the output port with JACK1. Therefore what do you mean special for JACK2 |
|
On Sun, 11 Oct 2020 at 23:29, Filipe Coelho ***@***.***> wrote:
@twischer-adit <https://github.com/twischer-adit> can you add a note
about port-tie? It is a deprecated API, but only because it ended up not
being used by client applications. as far as I know, ladish is the only one
that uses it
also, should be noted that this is a jack2-specific behaviour.
@wtay <https://github.com/wtay> is it safe to cache output port buffers
under pipewire-jack too?
In general no, the buffer memory can change due to reconnections, latency
changes or even when
more than 1 buffer is used between ports.
However... I've added a hack in PipeWire to detect and handle some cases
(calfjackhost).
Usually the caching is done outside of the processing loop with
jack_port_get_buffer() with a 0 frames
argument. If that is the case, I give a fixed area to the client that never
changes and copy the samples
to the real output buffer after calling the process callback.
Wim
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#602 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADUBCRX2BNGPYAHDQMODL53SKIPU3ANCNFSM4OIMBJIA>
.
|
This commit reverts 3d97601 ("More documentation in jack.h") partly.
The following call stack is used:
jack_port_get_buffer()
JackGraphManager::GetBuffer(jack_port_id_t, jack_nframes_t)
JackGraphManager::GetBuffer(jack_port_id_t)
JackPort::GetBuffer()
To call JackGraphManager::GetBuffer(jack_port_id_t, jack_nframes_t)
the object JackLibGlobals::fGlobals->fGraphManage is used. It is only
set in JackLibClient::Open(). Therefore it is not changed in the life
time of a JACK client.
In case port->fTied will be modified at runtime the returned audio
buffer would change. This variable can only be modified by the
deprecated jack_port_tie() function. Therefore as long as not calling
this deprecated function the audio buffer would not change.
The previous analyses is only valid for JACK audio output ports
(JackPortIsOutput). The creating JACK client can write to those
ports. For JACK audio input ports (JackPortIsInput) it is still not
allowed to cache the audio buffer address because for those ports the
returned audio buffer is depending on the port connections
(pipelining). The decision for the pipelining is done in
JackGraphManager::GetBuffer(jack_port_id_t, jack_nframes_t).